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1.  Introduction 


Tliia  report  provides  a  detailed  research  and  development  plan  for  the  development  and  deployment  of  an 
Ada  verification  capability.  The  background,  history,  and  goals  of  both  Ada  and  verification  are 
discussed.  Specific  recommendations  for  integrating  verification  technology  in  the  software  development 
process  (particularly  with  Ada)  are  presented.  The  necessary  research  items  to  be  pursued  in  support  of 
the  goals  are  also  presented. 

This  report  consists  of  two  major  sections  —  the  text  and  supporting  appendices  and  references.  The 
appendices  generally  describe  efforts  being  undertaken  in  various  areas  and  are  annotated  with  status  and 
points  of  contact  for  further  information. 


2.  Background 

The  need  for  application  of  verification  technology  to  the  development  of  software  written  in  Ada  is 
becoming  critical.  The  Ada  mandate  for  software  development  is  taking  hold,  and  other  issues  relevant  to 
the  Department  of  Defense  (particularly  security]  must  be  examined  in  the  light  of  this  mandate.  Tlie 
development  and  subsequent  publication  of  the  Trusted  Computer  Security  Evaluation  Criteria  (TCSEC) 
by  the  Department  of  Defense  Computer  Security  Center  (DoDCSC)  on  the  heels  of  that  of  the  Ada 
Language  Reference  Manual  (ANSI/MIL-STD-1815A-1983)  [Ada]  has  reinforced  the  need  to  address  the 
>ssue  of  Ada  verification.  A  recent  report  provided  by  the  DoDCSC  [Rowe]  describes  some  of  the  interests 
and  goals  of  the  Center  in  this  area. 

As  an  example  of  the  urgency  for  integration  of  verification  and  software  development  in  Ada,  there  are  a 
number  of  efforts  within  the  DoD  that  have  requirements  for  a  high  degree  of  security  (obtained  through 
the  use  of  verification  techniques)  and  for  implementation  in  Ada.  (Some  of  these  efforts  are  listed  in 
Appendix  A.)  Failure  to  integrate  these  two  technologies  could  jeopardize  the  goals  toward  which  these 
efforts  have  been  directed. 


2.1.  Programming  Languages 

Programming  languages  have  evolved  from  the  low  level  machine  codes  and  assembly  languages  of  the 
1950s  to  the  more  abstract  “high  level”  languages  of  the  19808  (Pascal,  C,  Ada,  etc.).  .-Uong  the  way, 
each  new  language  has  left  its  particular  mark  upon  the  computing  milieu.  The  presumption  about 
evolution  is  that  er.ch  succeeding  generation  of  languages  is  better  (in  some  objective  sense  of  the  wora) 
than  the  previous  generation.  Some  of  the  features  that  have  been  used  to  distinguish  new  programming 
languages  have  been  in  the  areas  of  data  abstraction,  conditional  constructs,  concurrency,  suitability  for  a 
particular  type  of  application  (business,  scientific,  list  processing,  communications  or  operating  systems). 

Although  the  evolution  of  programming  languages  has  provided  many  benefits  for  the  software 
development  profession,  there  are  also  drawbacks  to  the  evolution  of  programming  languages.  Foremost 
among  them,  and  perhaps  the  raison  d’etre  for  the  development  of  the  Ada  language,  is  the  incredible 
effort  required  over  the  life  cycle  of  software  development  projects  to  support  the  multitude  of  languag' s 
and  hardware  systems.  Another  major  drawback  is  the  limited  scope  of  hardware  upon  which  progra  ns 
written  in  a  part.icular  programming  language  may  be  executed.  Aside  from  such  languages  as  C, 
FORTRAN,  and  COBOL  few  programming  languages  (and  virtually  no  systems  programming  languages) 
are  widely  available  on  a  multitude  of  hardware  configurations.  The  goal  of  a  standardized  .A.da  is  that 
programs  written  to  execute  on  one  set  of  hardware  will  execute  on  other  sets  of  hardware  with  a 
minimum  of  modification. 


2.2.  Software  Development  Methodologies 


The  software  development  lifecycle  can  be  broken  down  into  four  general  phases:  requirements,  design, 
implementation  and  testing,  and  maintenance.  A  common  mechanism  for  graphically  displaying  these 
phases  is  the  standard  waterfall  diagram  shown  below,  and  basic  aspects  of  each  phase  are  presented.  As 
this  lifecycle  is  well  imderstood  and  applied,  each  area  moII  not  be  further  elaborated  here,  but  reference  is 
made  to  Section  6,  where  a  method  for  the  integration  of  verification  techniques  into  the  software 
development  lifecycle  is  presented. 
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Aside  from  the  generally  accepted  practices  of  software  development  such  as  top*down  development  (also 
called  structured  design,  hierarchical  development,  etc.)  a  particular  emphasis  is  being  placed  on  using 
what  is  known  as  an  object  oriented  approach  in  the  development  of  Ada  software.  [Berard]  This 
approach  applies  particularly  during  the  design  phase  of  software  development  and  attempts  to  place 
more  emphasis  on  the  development  and  use  of  abstract  data  types  in  the  software  development  cycle. 


2.3.  Verification  Technology 

Verification  is  the  process  in  which  mathematical  reasoning  is  used  to  show  that  a  system  satisfies  its 
requirements.  The  two  particular  types  of  verification  that  are  distinguished  are  those  of  design 
verification  and  of  implementation  verification.  Design  verification  is  the  process  of  showing  that  the 
design  of  a  system  (expressed  as  a  model  of  the  system  in  a  specification  language)  satisfies  the 
requirements  of  the  system.  The  requirements  of  the  system  are  usually  expressed  as  constraints  or 
invariants  on  the  system’s  behavior  —  relations  between  variables  making  up  the  state  of  the  system. 
Design  verification  is  performed  in  a  oon^procedural  language  that  expresses  what  is  being  accomplished, 
not  how  it  is  being  accomplished.  Design  verification  is  no  guarantee  that  the  resulting  system  will  indeed 
have  the  properties,  only  that  the  model  of  the  system  (as  expressed  in  the  design)  does.  Implementation 
verification 's  required  to  bridge  the  gap  between  the  design  and  the  executable  program.  Implementation 
verification  is  used  to  show 'm  a  constructive  manner  that  an  implementation  satisfies  its  requirements  by 
actually  developing  a  system.  The  r'quirements  of  the  system  are  expressed  as  pre*  and  post-K:onditions 
[Floydb?],  and  the  post-conditions  are  proven  from  the  pre-conditions  and  the  symbolic  execution  of  the 
constructed  system.  These  pre-  and  post-conditions  are  obtained  from  the  design,  and  any  attempts  to 
apply  implementation  verification  techniques  in  the  absence  of  a  design  (or  worse  yet,  in  a  post  hoe 
fashion,  after  the  program  has  been  developed)  are  subject  to  frustration  and  futility.  These  techniques 
must  be  integrated  into  the  software  development  lifecycle  (see  Section  6  for  such  a  discussion),  and  not 
applied  independently  of  such  lifecycle. 


Verification  technology  has  progressed  to  the  point  where  it  is  now  possible  to  apply  the  techniques  to  the 
development  of  small  systems  for  both  design  aind  implementation.  However,  use  of  the  technology  is 
limited  by  the  languages  available  for  describing  such  systems,  which  were  developed  as  many  as  ten 
years  ago,  and  do  not  reflect  the  state  of  the  art  in  programming  language  technology.  Another  difficulty 
preventing  the  use  and  application  of  verification  technologies  is  the  cost  involved.  Use  of  the  tools 
requires  individuals  with  a  high  level  of  formal  education,  and  requires  a  major  commitment  to  computing 
resources  in  order  to  be  able  to  be  applied  effectively.  For  this  reason,  larger  projects  desiring  to  apply 
verification  have  stopped  at  the  design  verification  level. 

In  the  past,  applied  verification  technology  has  been  driven  more  by  the  security  community  than  any 
other  community.  (For  a  listing  of  automated  verification  tools  and  their  applications,  see  Appendix  C.) 
There  are  also  some  related  issues  in  the  area  of  reliability  that  indicate  that  the  sorts  of  language 
limitations  necessary  for  allowing  the  proof  of  properties  relevant  to  reliability  are  the  same  sorts  of 
limitations  as  those  required  for  performing  verification. 

3.  Integrating  Ada  Verification  in  the  Software  Development  Process 

In  the  application  of  verification  technology  to  Ada,  there  are  three  approaches  that  can  be  taken; 

•  Follow  Current  Practices 

•  Design  Verification  with  Ada 

•  Integrated  Design  and  Implementation  Verification  with  Ada 
Issues  surrounding  each  of  these  alternatives  are  discussed  in  the  following  sections. 

3.1.  Current  Practices 

Ignoring  the  particular  requirement  of  Ada  with  respect  to  formal  verification  is  the  simplest  of  the 
alternatives  available.  It  requires  no  development  oi  additional  tools,  no  training  in  additional' 
technologies,  no  modification  of  the  current  development  approach.  From  the  point  of  view  of  secure 
applications,  the  implementation  language  used  in  the  development  of  an  Al  system  (currently  the 
highest  rating  given  by  DoDCSC)  is  irrelevant.  Only  design  verification  must  be  performed  (using  one  of 
the  “approved”  verification  systems  —  Gypsy,  HDM,  or  Aflirm),  and  only  informal  correspondence  with 
the  implementation  must  be  given  using  a  method  such  as  verification^  and  validation  (V&V).  This 
approach  does  make  the  informal  correspondence  significantly  harder  to  do  than  if  a  consistent  set  of 
languages  were  used,  but  is  currently  being  used  in  the  development  of  such  .Al  secure  systems  as  the 
Honeywell  SCOMP,  so  is  not  infeasible. 

The  drawback  to  this  alternative  is  that  it  is  necessary  for  the  system  developers  to  be  fiuent  in  multiple 
methodologies,  systems,  and  languages,  all  differing  from  one  another  if  the  use  of  some  form  of  design 
verification  is  desirable.  While  t'lis  may  be  an  acceptable  solution  in  the  very  short  term,  it  will  not  be 
sufficient  for  the  long  term,  due  to  the  complexities  of  the  various  systems.  Furthermore,  this 
fragmentation  of  the  development  teams  along  the  J'nes  of  specialization  (design,  verification, 
implementation)  will  increase  the  overhead  associated  with  program  development. 

t  The  key  word  in  this  sentence  is  ‘‘sdditionsl"  —  the  tools  snd  technologies  Tor  verification  will  still  bare  to  be  available,  and 
individuals  still  trained  in  their  use  and  application. 

ft  Unfortunate,  but  the  same  word  is  used  in  differring  contexts  by  different  people  to  mean  different  things.  Use  of 
''verification”  in  this  context  is  what  has  lead  to  the  concept  of  po$t  hoc  formal  verification,  which  is  totally  inappropriate. 


3^.  Design  Verifiestion  -with  Ads 

A  second  alternative  that  can  be  taken  is  the  use  of  Ada  as  a  design  language,  both  for  implementing 
standard  requirements  and  design  methodologies,  as  well  as  in  preparation  for  design  verification.  The 
requirements  and  design  phases  could  all  be  done  in  Ada  (or  an  Ada  Program  Design  Language  [PDL]), 
and  with  the  development  of  supporting  verification  tools,  design  verification  performed.  This  would 
significantly  decrease  the  gap  between  the  design  being  verified  and  the  implementation.  It  would  also 
o^y  require  the  developers  to  be  familiar  with  a  much  smaller  number  of  methodologies,  permitting  a 
more  unified  approach  to  the  development  of  verifiably  secure  systems  than  the  current  disjointed 
approach  being  applied. 

The  glaring  drawback  to  this  alternative  is  the  lack  of  automated  tools  for  the  support  of  design  and  for 
verification,  as  well  as  the  lack  of  a  suitable  language  definition  for  design  specification.  Although  some 
tools  have  been  developed  for  the  use  of  Ada  as  a  design  language,  many  of  them  are  little  more  than 
subsets  of  Ada  front  ends.  There  are  no  tools  available  for  the  verification  of  designs  written  using  an 
Ada  PDL,  nor  do  there  appear  to  be  any  in  development.  The  only  existing  serious  specification  language 
particularly  directed  toward  .\da  (Anna  [Anna])  has  only  limited  application  at  the  current  time.  .Anna 
does  not  contain  a  suflicient  sec  oi  constructs  for  performing  design  verification,  but  rather  is  geared  more 
towards  the  development  of  runtime  checking.  Furthermore,  Anna  is  not  integrated  with  an  .Ada 
compiler,  but  must  be  run  as  a  separate  tool.  An  additional  drawback  to  this  approach  is  the  lack  oi  a 
formal  semantic  definition  of  the  constructs  in  the  portion  of  the  language  used  for  design  (the  non¬ 
procedural  portions)  verification.  Without  such  a  semantic  definition  it  remains  impossible  to  reason 
about  program  designs  and  prove  properties  of  these  designs. 

3.3.  Integrated  Design  and  Implementation  Verification  with  Ada 

The  final  alternative  to  applying  verification  technology  to  Ada  would  be  to  perform  implementation 
verification  as  well  as  design  verification.  This  alternative  would  provide  the  most  integrated  approach  of 
verification  in  the  software  development  process,  directly  following  design  verification  as  one  step  in  the 
total  verification  process.  It  allows  the  greatest  amount  of  formalism  to  be  applied  in  the  development  of 
software,  and  allows  verification  to  be  applied  down  to  the  source  code  level.”  However,  this  alternative  is 
currently  infeasible  from  both  a  theoretical  and  a  practical  point  of  view  (particularly  so  for  Ada).  It 
inherits  all  the  difiiculties  of  performing  design  verification  mentioned  above,  as  well  as  some  Ada  unique 
problems.  In  addition  to  a  semantics  for  the  non-procedural  portions  of  the  language,  the  procedural 
portions  must  also  have  their  semantics  formally  defined.  Additional  tools  for  processing  the  programs, 
their  specifications,  and  symbolic  execution  of  the  programs  must  be  developed.  Tools  for  proving  the 
correspondence  between  the  specification  and  the  implementation  (verification  conditions  resulting  from 
the  symbolic  execution)  must  also  be  developed. 

4.  Goals 

This  section  describes  goals  to  be  pursued  in  developing  and  deploying  an  Ada  verification  capability. 
Each  goal  is  described  in  terms  of  those  aspects  of  it  that  may  be  completed  in  the  near-term  (up  to  three 
yean,  now  to  1988)  and  long-term  (more  tham  three  yean,  past  1988).  This  time  span  is  :hosen  as  the 
definition  of  the  Ada  language  is  currently  “frozen”  until  1988,  and  it  would  be  beneficia'  to  have  some 
recommendations  available  to  the  language  maintenance  organization  when  the  time  for  review  of  the 
language  arrives.  The  fint  two  alternatives  given  in  the  previous  section  (current  practices,  and  design 
verification  with  Ada)  help  achieve  short  term  goals,  while  the  third  alternative  (integrated  design  and 
implementation  verification  with  Ada)  is  a  more  long  term  goal. 

t  VerificatiOD  could  coueeirablr  be  applied  to  eren  lower  levels,  to  microprocessor  instruction  ec's,  and  even  to  gate  levels, 
although  the  techniques  and  mechanisms  required  for  this  level  of  veriScstion  (to  saj  nothing  of  the  hardware  resources  required) 


4.1.  Form&I  Semantics  of  Ada 

A  major  goal  that  must  be  obtained  before  any  significant  application  of  verification  technology  may  be 
made  with  Ada  is  the  development  of  a  formal  semantics  of  the  language.  As  a  formal  semantics  of  the 
language  was  not  developed  in  concert  with  the  development  of  the  language,  it  might  not  be  possible  to 
develop  a  semantics  for  the  entire  language.  However,  if  semantics  for  only  a  portion  of  the  language  can 
be  developed,  the  implication  is  that  only  that  portion  of  the  language  may  be  used  for  systems  that  will 
require  verification.  There  are  a  number  of  efforts  already  underway,  however  they  suffer  from  disjoint 
interests,  approaches,  and  are  not  well  coordinated  with  one  another  in  order  to  provide  a  single  definitive 
result.  (Some  of  these  efforts  are  noted  in  Appendix  E,  Sections  12.1.3  and  12.3.)  Once  the  semantics  are 
developed,  progress  may  be  made  toward  development  of  automated  tools  for  the  support  of  verification. 

4.2.  Specification  Language  for  Ada 

Another  goal  that  must  be  attained  before  the  verification  of  Ada  programs  may  be  undertaken  is  the 
development  of  a  specification  language  for  Ada.  Both  a  design  specification  language  and  an 
implementation  specification  language  (hopefully  correlated  in  order  to  allow  both  forms  of  verification  to 
be  applied)  will  have  to  be  developed.  Progress  has  been  made  in  this  area  with  the  Anna  language,  (see 
Appendix  D,  Section  11.1)  and  effort  is  underway  in  more  general  areas  of  specification  (see  Appendix  £, 
Section  12.1.4). 

4.3.  Automatad  Tools  for  Verification 

A  goal  in  the  area  of  verification  (aa  well  as  software  development)  has  been  the  development  of 
supporting  automated  tools.  These  tools  aid  the  developers  by  performing  as  much  of  the  detailed 
bookkeeping  and  other  automatable  work  as  possible,  allowing  the  developers  to  use  their  time  in  other, 
more  creative  and  productive  means.  Another  distinct  advantage  that  r^ults  from  the  development  of 
automated  tools  (used  as  a  primary  argument  for  the  development  of  prototypes)  is  the  opportunity  to  use 
the  tools  as  an  embodiment  of  the  issue  at  hand  to  provide  for  further  understanding  of  the  situation. 
While  applying  verification  to  Ada,  the  development  of  such  tools  aa  verification  condition  generators  and 
symbolic  evaluators  would  allow  testing  of  the  semantics  being  developed  to  insure  that  they  can  be 
applied  in  such  an  environment,  and  that  they  indeed  correspond  to  the  execution  of  the  constructs  in  the 
language. 

There  are  two  possible  mechanisms  by  which  automated  tools  for  the  support  of  verification  can  be 
developed  —  modification  of  existing  tools,  and  the  development  ab  initio  of  a  verification  system.  The 
former  is  clearly  a  short-term  goal,  while  the  latter  one  of  much  longer  term. 

4.3.1.  Modification  of  Existing  Verification  Tools 

The  modification  of  existing  verification  tools  provides  a  mechanism  whereby  the  investment  in  those  tools 
can  be  leveraged  to  make  as  quick  as  possible  a  return  on  that  investment  m  the  area  of  Ada  verification. 
Many  of  the  tools  that  have  been  developed  (expression  simplifiers,  symbolic  execution  and  interpretation, 
theorem  provers)  are  in  part  or  in  whole  language-independent,  and  should  be  amenable  to  minor 
modification  for  application  in  the  Ada  verification  arena.  Another  benefit  to  use  of  modified  tools  would 
be  the  ability  of  the  tools  to  serve  as  a  prototype  testbed  for  evaluation  of  proposed  semantics  of  the 
language,  and  allow  experimentation  without  the  large  investment  required  by  the  full-scale  development 
of  a  new  system. 


c; 


tft  eumntly  btyood  tht  stue  of  the  irt. 


For  current  efforts  addressing  this  goal  see  Appendix  D,  particularly  Sections  11.3  and  11.4,  and  Appendix 
E,  Section  12-1.2. 

4  J.2.  Development  of  New  Verification  Tools 

The  development  of  new  verification  tools  provides  the  opportunity  to  make  a  cohesive  set  of  tools 
particularly  geared  toward  the  needs  of  systems  developers  using  Ada.  It  also  provides  an  opportunity  to 
develop  the  tools  themselves  in  Ada  (leveraging  off  of  the  experience  of  previous  developments),  as  well  as 
to  possibly  integrate  the  tools  into  environments  particularly  targeted  for  Ada  development  (e.g.,  ALS). 
Experience  with  Ada  is  somewhat  limited  at  the  moment,  and  development  systems  for  Ada  are  still  at  a 
quite  immature  stage.  This  would  indicate  that  caution  should  be  taken  before  attempting  to  commit 
significant  resources  to  such  a  development.  Another  reason  for  hesitancy  in  committing  to  such  an  effort 
is  the  lack  of  an  established  formal  semantics  for  Ada,  a  necessary  prerequisite  to  such  effort. 

5.  Researeh 

This  section  lists  particular  areas/sub*areas  of  Ada  and  verification  for  which  additional  research  may  be 
necessary,  both  separately  and  in  conjunction  with  one  another. 

5.1.  Verifiability  of  Ada 

Perhaps  the  greatest  obstacle  to  the  application  of  verification  technology  to  Ada  is  the  fact  that  the 
language  was  not  designed  as  a  verifiable  language.  Furthermore,  the  size  and  complexity  of  the  language 
make  it  difficult  to  understand,  from  the  point  of  view  of  verifiability,  not  only  the  constructs  in  the 
language  but  also  interactions  between  many  of  the  constructs.  One  solution  that  has  been  proposed  for 
dealing  with  this  complexity  is  the  enforcement  of  a  “verifiable  subset”  of  the  language  in  situations 
where  verification  is  applied  to  Ada  software  development. 

The  greatest  need  in  research  in  .'Vda  for  verification  is  the  development  of  a  formal  semantics  for  the 
language.  Without  such  a  semantics,  it  is  impossible  to  do  symbolic  evaluation  of  programs  and  provide  a 
verification  condition  generator.  Several  efforts  have  been  undertaken  in  the  development  of  semantics  for 
portions  of  the  language,  [LuckhamSO,  Pneulid2,  Barringer32,  Gerth82,  GerthSS],  but  additional  work 
needs  to  be  performed  to  coordinate  these  efforts  and  unify  their  results. 

In  addition  to  the  semantics  of  the  language,  the  concurrent  aspects  of  the  language  need  further 
investigation,  since  they  cause  considerable  difficulty  in  use  of  the  language.  Lastly,  the  indeterminancy 
features  of  the  language  need  to  be  resolved  in  such  a  way  as  to  make  the  language  “predictable”. 

5.1.1.  Language  Subsets 

Although  the  issue  of  language  subsets  for  compilers  has  long  been  considered  anathema  to  the  Ada  .Joint 
Program  Office,  such  a  requirement  is  not  applicable  in  the  area  of  verification.  It  is  wholly  app-opriate 
to  use  that  portion  of  the  language  that  is  amenable  to  verification,  and  use  any  validated  compiler  for 
the  generation  of  executable  code.  Determination  of  appropriate  subsets)  to  be  used  in  software 
development  requireing  verification  could  use  only  that  “predictable”  subset  of  the  language  or  follow  the 
“clusters”  approach  (see  Section  12.1.6). 


S.1.2.  Formal  Semantica 


The  Ada  language  divides  quite  nicely  into  two  areas  in  which  its  semantics  can  be  developed  —  the 
sequential  and  the  concurrent  aspects  of  the  language.  Further  subareas  of  research  in  these  two  areas  are 
described  in  the  following  sections. 

5.1.2.1.  Sequential  Constructs  in  Ada 

For  the  most  part,  the  sequential  constructs  in  Ada  are  similar  to  those  found  in  other  high  level 
languages  (Pascal,  C,  CLU,  Gypsy),  and  their  semantics  can  be  easily  determined  from  the  semantics  of 
the  corresponding  constructs  in  the  other  languages.  There  are  two  particular  areas  that  will  require 
additional  effort:  generics  and  exceptions. 

5.1.2.1.1.  Generics 

Aside  from  the  issue  of  concurrency  in  the  language,  the  second  moat  difficult  portion  of  the  language  is 
that  of  generics  [Ernst,  YoungSOj.  While  the  'ise  of  generics  is  a  very  powerful  concept,  care  must  be 
taken  to  ensure  that  the  semantica  are  well-defined,  and  that  they  are  amenable  to  automatic  processing 
for  use  in  verification  tools. 


5.1.2.1J2.  Exceptions 

Exceptions,  per  ee,  are  not  a  new  feature  in  programming  languages  [Good78,  Goodenough75].  In  Ada 
however,  exceptions  have  been  promoted  to  a  more  prominent  place  in  the  language,  and  must  be  treated 
with  as  much  care  as  other  constructs  in  the  language,  not  as  an  add-on.  Although  some  work  has  been 
done  in  developing  a  semantics  for  Ada  expressions  [LuckhamSO],  this  work  needs  to  be  integrated  with 
the  development  of  the  semantics  for  the  remainder  of  the  language. 

5.I.2.2.  Concurrent  Constructs  in  Ada 

As  with  exceptions,  a  semantics  for  the  concurrent  constructs  in  Ada  has  been  under  investigation 
[Barringer82|.  And,  like  the  work  in  the  semantics  of  exceptions,  this  work  needs  to  be  integrated  with 
the  efforts  in  semantics  of  the  remainder  of  the  language. 

5.1.3.  Model  of  Concurrency 

As  mentioned  above,  part  of  the  difficulty  in  obtaining  an  appropriate  semantics  of  the  concurrent 
constructs  of  the  Ada  language  has  been  due  to  the  choice  of  the  model.  The  Ada  model  for  concurrency 
is  that  of  the  rendesvous.  A  model  more  conunonly  used  in  languages  for  verification  is  that  of  message 
passing.  The  two  are  computationally  equivalent,  however,  the  message  model  becomes  more  difficult  for 
verification  unless  restrictions  on  other  coF.munications  are  present  (e.g.,  no  global  variables,  a  la  Gypsy), 
and  this  restriction  was  deemed  too  stiff  for  the  language  definition.  Additional  work  needs  to  be  done  to 
see  if  the  rendezvous  model  can  be  made  more  amenable  to  verification,  and/or  if  a  message  passing 
mechanism  could  be  used  in  Ada. 


5.1.4.  Predictability 


Aside  from  the  non-determinism  resulting  from  the  concurrency  in  the  language,  another  characteristic  of 
the  Ada  language  is  its  non-predictability.  This  characteristic  arises  from  such  statements  in  the 
Language  Reference  Manual  as  in  Section  ll.S  (2)  Exeeptiont  and  Optimization: 

When,  on  the  other  hand,  the  order  of  certain  actions  is  not  defined  by  the  language,  any  order  can  be  used 
by  the  implementation. 

or  Section  6.4  (6)  Subprogram  CaUt 

The  parameter  associations  of  a  subprogram  call  are  evaluated  in  some  order  that  is  not  defined  by  the 
language.  Similarly,  the  language  rules  do  not  define  in  which  order  the  values  of  in  out  or  out  are  copied 
back  into  the  corresponding  actual  parameters  (when  this  is  done). 

There  are  a  number  of  solutions  to  the  difficulty  encountered  in  predictability  of  programs.  The  most 
straightforward  approach  would  be  to  eliminate  these  difficulties  from  the  language.  If  the  language 
definition  doesn’t  specify  an  ordering  in  such  Liutances,  it  should  be  appropriate  to  pick  a  particular 
ordering  (one  that  would  be  amenable  to  verification),  and  recommend  that  it  be  instantiated  as  the 
accepted  one.'  The  adoption  of  a  firm  policy  that  any  Adarimplemented  system  to  be  certified  at  the  B2 
or  higher  level  must  be  implemented  in  “predictable  Ada”  might  be  considering. 


5.2.  Verification 

In  the  area  of  verification,  there  are  a  number  of  issues  that  relate  to  the  continuing  language 
developments  that  have  not  yet  found  solutions.  In  particular,  the  areas  of  concurrency,  fault  tolerance, 
and  real  number  arithmetic  remain  to  have  significant  strides  made  before  becoming  viable  for  use  in 
development  of  systems. 


5.2.1.  Concurrency 

Verification  of  general  concurrency  is  a  difficult  task,  due  to  the  usual  “flat”  address  space  available  in 
most  programming  languages.  With  suitable  restrictions  on  access  co  variables  and  communications 
between  concurrent  processes  (such  as  in  Gypsy),  some  verification  of  concurrent  processes  can  be 
performed.  It  would  be  beneficial  to  investigate  other  models  of  concurrency,  such  as  the  rendezvous 
mechanism  of  Ada,  to  find  ways  of  making  them  more  amenable  to  verification. 


5.2.2.  Fault  Tolerance  /  Reliability 

Fault  tolerance  has  long  been  a  well  understood  and  accepted  practice  in  hardware  design,  but  the 
techniques  thus  used  have  not  been  applied  in  the  area  of  software,  or  even  systems  design.  One 
difficulty  in  this  area  is  the  lack  of  a  suitable  model  of  computation  for  fault  tolerance  in  w>.ich 
verification  co’ild  be  investigated. 


t  It  is  worth  noting  thst  it  is  not  only  the  TtriHestion  community  tbst  btt  expressed  interest  in  solution  to  this  issue  —  com¬ 
piler  Tendon  bsre  the  same  desire  to  see  the  Isngusge  definition  tightened. 


5^.3.  Floating  Point  Arithmetic 

Floating  point  arithmetic  has  been  an  area  in  verification  that  has  been  almost  totally  ignored.  The 
major  reason  for  this  situation  is  the  fact  that  an  appropriate  idealization  of  floating  point  arithmetic  has 
not  been  developed  that  would  be  appropriate  for  a  number  of  hardware  implementations  and  amenable 
to  analysis  for  verification  efforts. 

5^.  Ada  and  Verification 

Aside  from  the  other  issues  that  arise  in  the  application  of  verification  technology  to  the  development  of 
software  in  Ada,  a  serious  effort  should  be  placed  on  looking  at  the  effect  of  the  language  on  verification 
methodologies.  Although  it  appears  at  first  glance  that  verification  should  be  easily  integrated  into  the 
software  development  process  (see  Section  6  below),  there  may  remain  peculiarities  with  regard  to  Ada, 
due  to  the  advanced  feattires  present  in  the  language.  These  features,  not  present  in  other  languages 
designed  for  verification,  might  inhibit  the  choice  of  methodologies  available  for  verification. 

0.  Verification  and  the  Softwsire  Development  Process 

This  section  describes  an  approach  for  making  verification  an  integral  part  of  the  software  development 
process.*  It  recommends  where  those  issues  raised  in  Section  3  can  be  addressed,  and  suggests  efforts  to  be 
undertaken  as  well  as  policy  to  be  encouraged  in  order  to  achieve  the  desired  goals,  both  in  the  short  and 
the  long  terms.  The  various  areas  in  which  verification  is  applied  directly  follow  the  waterfall  diagram 
provided  in  Section  2.2. 

6.1.  Requirements 

Although  there  is  limited  application  of  verification  technology  to  the  requirements  phase  of  a  software 
development  effort,  it  is  appropriate  that  verification  be  taken  into  consideration  at  this  stage.  If 
verification  is  intended  for  an  effort,  it  will  be  beneficial  to  start  with  a  formal  statement  of  the 
requirements.  Such  a  statement  could  serve  as  a  “contract”  between  the  developers  of  a  system  and  any 
contracting  party.  An  example  of  an  informal  requirements  presentation  (the  KAIS  FEU)  in  [Smitb84j  is 
turned  into  a  formal  one  in  [Good84a]. 

6.2.  Design 

In  the  design  phase,  verification  can  be  applied  to  show  that  the  design  indeed  satisfies  the  requirements 
developed  in  the  previous  step.  This  step  can  be  taken  in  conjunction  with  the  design  development, 
although  many  times  the  design  is  developed  without  any  regard  for  verification,  and  the  verification  is 
not  considered  until  after  the  design  is  completed.  It  is,  however,  at  this  stage  that  the  pressure  to 
produce  a  running  system  increases,  and  projects  often  split  into  two  directions  —  prototype  development 
and  verification.  This  split  has  the  unfortunate  result  of  not  allowing  any  feedback  from  the  design 
verification  to  affect  the  design,  and  subsequently  the  implementation.  As  a  result,  the  system  whose 
design  was  verified  may  not  correspond  to  the  system  implemented.  This  appears  to  be  the  case  reported 
in  [SIFT].  A  design  (and  implementation)  verification  where  the  design  verification  indeed  corresponds  to 
the  implementation  is  presented  in  [SmithSl],  while  the  design  verification  of  the  KA^S  FEU  mentioned 
above  is  presented  in  .[Good84ej . 

t  A  ptrtieulsrly  good  trestis*  oo  tht  methodology  for  applying  Tcrification  technology  in  the  software  development  process 
particularly  oriented  to  the  TCSEC  At  level  of  certification  can  be  found  in  |Good84d|. 


8  Implementation  and  Testing 


With  an  approach  to  program  development  that  doesn’t  allow  (or  encourage)  the  implementation  to 
progress  any  faster  thu  the  implementation  verification,  application  of  verification  technology  in  the 
implementation  and  testing  phase  is  straightforward.  As  each  succeeding  level  of  software  is  developed,  it 
is  proven  correct  with  respect  to  its  specification.  By  the  time  the  development  reaches  the  lowest  levels 
of  the  implementation,  each  of  the  higher  levels  will  have  been  verified  in  turn. 

One  area  where  verification  technology  that  has  been  overlooked  in  the  software  development  process  is 
the  automated  development  of  teat  cases,  particularly  for  modules.  Implementation  verification  requires 
the  development  of  verification  conditions,  obtained  by  a  symbolic  evaluation  of  the  program.  This 
symbolic  evaluation  identifies  the  various  paths  possible  during  a  program’s  execution,  and  could  be  used 
to  determine  a  set  of  teat  inputs  that  could  exhaustively  exercise  particular  modules. 

Another  application  of  verification  technology  is  in  the  area  of  “reusable”  software.  Once  a  particular  set 
of  software  (e.g.,  packages,  libraries,  etc.)  were  developed  and  verified,  they  could  be  used  in  the  software 
development  process  without  requiring  the  reimplementation  and  reverification  of  their  functionality.  If  a 
particTilar  application  can  leverage  off  the  work  in  a  similar  application,  perhaps  the  benefit  of  reusable 
theories  [Go^82cj  and  verified  libraries  can  also  be  put  to  use. 


8.4.  Maintenance 

Maintenance  in  the  software  development  lifecycle  is  what  occurs  after  the  software  has  been  “released”, 
and  recommendations  for  changes,  updates,  fixes,  etc.  start  being  encountered.  It  is  this  phase  that  lends 
justification  to  the  claim  of  the  non-sequential  aspect  of  the  waterfall  diagram  presented  in  Section  2.2. 
Although  at  some  point  in  the  system  development  process  it  may  be  desirable  to  take  the  current  system, 
designate  it  as  a  prototype,  and  proceed  from  scratch  with  a  new  development,  more  often  the  current 
system  is  modified  to  add  an  additional  feature  or  modify  the  manner  in  which  a  particular  feature 
operates.  Most  often,  this  modification  is  performed  by  feeding  back  to  the  implementation  and  testing 
phase.  However,  to  keep  the  entire  development  lifecycle  in  mind,  it  is  appropriate  to  return  to  the 
requirements  phase,  and  indicate  how  the  change  affects  the  requirements,  the  design,  and  the 
implementation  and  testing  phase.  This  is  an  area  that  is  also  npe  for  application  of  verification 
technology. 

The  most  applicable  principle  of  verification  technology  for  use  in  the  maintenance  phase  of  software 
development  is  that  of  incremental  methods  [Moriconi77|.  Similar  in  concept  to  the  principle  of  separate 
compilation  (available  in  many  languages  and  compilers,  and  made  explicit  in  Ada),  the  principle  of 
incremental  methods  for  verification  technology  states  that  only  those  portions  of  a  system  that  have  been 
changed  need  to  be  re-verified  for  the  system  to  remain  “proven”.  As  (for  example)  the  reimplementation 
of  (the  body  of)  a  function  or  procedure  in  a  package  in  Ada  does  not  require  the  recompilation  of  those 
other  units  that  depend  only  upon  its  interface  specification,  so  the  reimplementation  of  a  unit  that 
continues  to  meet  its  pre-  and  post-condition  specifications  does  not  require  the  reverification  of  any  other 
units. 

7.  RsMareh  and  Developmeat  Plan 

This  section  describes  the  particular  research  and  development  efforts  that  are  recommended  for  the 
deployment  of  Ada  verification  capabilities.  Time  schedules,  estimated  levels  of  effort,  and 
interdependencies  are  provided  both  in  a  narrative  and  a  tabular  form.  Such  estimates  must  be  tempered 
with  the  understanding  that  independent  efforts  such  as  would  be  expected  of  such  large  projects  would 
incur  additional  startup  overhead  and  initial  familiarity  learning  curves.  It  must  also  be  understood  that 
a  coordination  of  these  efforts  will  also  require  additional  effort.  Finally,  these  estimates  are  only  that  — 


estimatca.^  Although  baaed  upon  the  expehencea  of  others  in  performing  similar  work  in  the  veriScation 
community,  these  are  extrapolations  into  an  unknown  arena,  with  many  possible  pitfalls  present. 

The  schedule  as  presented  is  predicated  on  a  number  of  assumptions.  Foremost  among  those  is  the  ability 
to  start  the  efforts  immediately.  While  this  may  be  a  fallacious  assumption,  it  is  possible  that  the  existing 
efforts  may  be  leveraged  off  of  in  order  to  overcome  the  initial  startup  and  learning  overhead.  Secondly, 
the  schedule  attempts  to  complete  as  much  work  by  the  end  of  1981^  in  order  to  be  able  to  provide  input 
to  the  language  maintenance  committee,  which  will  be  considering  language  changes  in  that  time  frame. 

7.1.  Formal  Semantics  of  Ada 

The  development  of  the  Ada  language  itself  was  a  multiyear  task,  requiring  the  resources  of  numerous 
individuals.  As  a  result,  the  developments  of  a  semantics  for  the  language  ought  to  have  the  same  flavor, 
and  is  likely  to  have  a  similar  extent.  Time  should  be  allowed  for  review  of  any  results,  and  for 
experimentation  with  prototype  verification  systems  to  investigate  the  appropriateness  of  the  developed 
semantics. 

The  two  areas  of  Ada  for  which  semantics  must  be  developed  are  the  sequential  and  the  concurrent  parts 
of  the  language.  The  split  is  a  natural  one,  and  lends  itself  to  a  useful  separation  of  concerns. 

7.1.1.  Sequential  Portion 

A  number  of  efforts  have  begun  to  address  this  issue  (see  Appendix  E,  Sections  12.1.3  and  12.3),  although 
no  results  have  been  published  or  reviewed  as  of  yet.  It  is  estimated  that  this  effort  will  require  ten  staff- 
years  over  two  and  one  half  calendar  years,  including  serious  outside  review. 

7.1.2.  Concurrent  Aspects 

Once  a  semantics  for  the  sequential  portion  of  the  language  has  begun,  work  on  the  concurrent  aspects 
should  be  started  and  integrated  with  the  sequential  work.  It  is  a  vital  necessity  that  these  two  effort  be 
done  in  concert,  so  as  not  to  develop  a  semantics  for  the  sequential  portion  of  the  language  that  is 
incompatible  with  a  semantics  for  the  concurrent  aspects.  This  effort  is  estimated  at  six  staff-years  over 
two  calendar  years. 

7.2.  Specification  Language 

Although  not  specifically  designed  as  a  language  for  the  proof  of  programs  concerning  Ada,  the  Anna 
specification  language  provides  an  excellent  starting  point  for  the  development  of  a  specification  language 
for  verification  work.  Modifications  in  order  to  more  adequately  support  verification  oriented  constructs 
should  be  investigated,  and  the  language  extended  to  handle  these  constructs.  F urthermore,  integration  of 
a  specification  mechanism  to  describe  concurrency  shoiJd  be  performed. 


t  These  estimates  should  probsbir  be  considered  ss  the  midpoint  in  s  range,  running  from  possibir  twenty  percent  lower  to 
twenty  percent  higher. 


7^.1.  Sequential  Portion 


With  the  Anna  language  as  a  basis  for  the  development  of  a  specification  language,  it  will  be  necessary  to 
extend  the  language  to  include  more  proof-theoretic  constructs  necessary  for  doing  implementation 
verification.  This  effort  is  estimated  at  three  staff-years  over  one  calendar  year. 


7^.2.  Concurrent  Aspects 

In  concert  with  the  development  of  the  formal  semantics  for  the  concurrent  aspects  of  the  language,  and 
after  the  work  on  the  specification  language  for  the  sequential  portion  of  the  language  has  begun,  work  on 
integrating  specification  constructs  for  the  concurrent  aspects  of  the  language  should  be  integrated  into 
the  specification  language.  As  with  the  work  on  the  semantics,  this  effort  should  be  done  in  concert  with 
the  effort  on  the  sequential  portion  of  the  specification  language  to  insure  their  compatibility.  This  effort 
is  estimated  to  require  two  staff-years  over  one  calendar  year. 


7^.  Automated  Verification  Toois 

There  are  two  possibilities  for  the  development  of  automated  tools  in  the  support  of  verification  activities 
—  prototype  tools  for  the  short-term,  and  (possibly  ALS)  integrated  tools  for  the  long  term. 


7^.1.  Prototype  Tools 

A  number  of  efforts  are  underway  in  the  development  of  prototype  tools  for  the  support  of  verification 
with  Ada.  Some  known  efforts  are  listed  in  Appendix  D,  particularly  Sections  11.3  and  11.4.  These  sorts 
of  efforts  should  be  encouraged  in  the  short  term  (up  to  two-three  years  calendar  time)  in  order  to  gain 
more  experience  with  the  similarities  and  differences  between  Ada  and  other  languages,  and  the  way  in 
which  verification  impacts  the  use  of  Ada  as  a  development  language.  The  support  of  two  such  projects 
over  the  next  two  and  one  half  years  could  amount  to  some  ten  staff-years. 


7^.2.  Integrated  Tools 

Plans  should  be  laid  for  the  long  term  development  of  an  Ada  verification  capability  that  would  be 
integrated  with  the  remainder  of  a  development  system  currently  envisioned  for  software  development  in 
Ada.  A  significant  amount  of  understanding  and  experience  with  applied  verification  using  Ada  would 
have  to  be  obtained,  and  used  in  the  development  of  such  a  system. 

Current  verification  systems  are  the  result  of  many  people’s  efforts  over  a  significant  period  of  time,  and  it 
ought  not  to  be  expected  that  attacking  the  Ada  problem  will  be  any  simpler.  A  critical  mass  of 
approximately  six  individuals  working  over  a  three  year  span  is  probably  a  lower  bound  on  the  estimate 
necessary. 


7.4.  Tables 

The  following  tables  provide  the  information  just  presented  in  a  graphic  tabular  form.  The  first  table 
describes  the  recommended  time  schedules  for  the  various  tasks,  and  the  second  table  the  staffing  level. 
Again,  these  tables  are  predicated  on  starting  immediately,  and  attempting  to  complete  as  much  efibrt  as 
possible  to  allow  input  to  the  language  maintenance  committee  by  1988. 
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8.  Appendix  A  •  Current  Ada  Efforts  Requiring  Verification 

This  appendix  lists  the  known  efforts  that  require  the  use  of  Ada  and  have  some  requirements  for 
verification  of  one  sort  or  another.  Current  status  of  the  efforts  and  a  relevant  point  of  contact  are 
identified. 

8.1.  Inter>Servieea/ Agency  Automated  Message  Processing  Environment  (I-S/A  AMPE) 

The  AMPE  project  requires  the  use  of  Ada  as  a  PDL  for  the  system  design  as  well  as  the  accreditation  of 
the  system  as  an  AI  system  according  to  the  TCSEC. 


8.2.  Department  of  Defense  Intelligence  Information  System  (DoDIIS) 

The  DoDIIS  is  currently  investigating  the  use  of  Ada  on  a  project-wide  basis  for  re-implementation  of  it 
database  systems.  The  are  no  known  verification  requirements  per  se  at  this  time. 

Defense  Intelligence  Agency 
Attn.  RSElB  (Cpt.  Frank  Stellar) 

Washington,  1X7  20301-6111 
(202)-373-3012 


8.3.  World-Wide  Military  Command  and  Control  System  Information  System  (WIS) 

The  WIS  has  a  mandated  requirement  for  a  majority  of  the  system  to  be  written  in  Ada,  and  an  unstated 
requirement  for  multi-level  security,  but  no  explicit  requirement  for  verification. 

Col.  William  Whitaker 
WIS  JPMO/ADT 
Washington,  DC  20330-6600 
(703)-285-5065 

8.4.  Army  Secure  Operating  System  (ASOS) 

The  Army  Sectire  Operating  System  (formerly  Military  Computer  Family  Operating  System  -  McFOS)  is 
a  program  with  the  goal  of  developing  an  Al  operating  system  coded  in  Ada  with  the  express  purpose  of 
running  Army  tactical  applications  also  coded  in  Ada.  The  system  is  currently  undergoing  prototyping 
with  the  top  level  specification  being  done  inhouse  in  HDM  Special,  and  the  preliminary  software  compiled 
using  the  ICSC  compiler.  Plans  are  to  migrate  to  the  Ada  Language  System  (ALS)  as  it  becomes 
available. 

Eric  Anderson 
TRW 
R2/1124 
1  Space  Park 

Redondo  Beach,  CA  90278 
(213)-535-5776 


8^.  Secure  Conununicetiona  Protocol 

The  Network  Division  of  the  Department  of  Defense  Computer  Security  Center  is  investigating  the  issue 
of  the  development  of  secure  communications  protocols  using  Ada  and  using  verification  techniques  to 
prove  the  security  of  the  protocols. 

Ken  Rowe 
DoDCSC,  C3 
9800  Savage  Road 

Ft.  George  G.  Meade,  MD  20755-6000 

(301>>8S9-67g0 

DDN:  rowe<9tycho 


0.  Appendix  B  *  Verification  in  the  Software  Development  Process 


This  appendix  lists  the  know  efforts  attempting  to  determine  appropriate  methodologies  /  metaphors  for 
the  use  of  verification  in  the  software  development  process.  It  lists  those  that  are  specific  to  the  Ada 
language  as  well  as  those  that  are  not. 

0.1.  ACM  National  SIGAda  Design  Methodology  Committee 

This  committee  chair  is  coordinating  the  Ada  Verification  work  with  other  efforts  underway  m  the  area  of 
the  methodology  of  Ada  software  development.  A  presentation  of  the  results  of  the  first  EDA  workshop 
will  be  presented  at  the  SIGAda  conference  this  summer. 

Alton  Brintzenhoff 
SYSCON  Corp. 

3090  Sherman  Street 
San  Diego,  CA  92110 
(019>>2g6-0085 
DDN:  sci>ada<9eclb 


0.2.  Verification  in  Life  Cycles 

See  the  corresponding  entry  in  Appendix  D,  Section  11.4.5,  for  a  working  subgroup  resulting  from  the 
First  IDA  Workshop  on  ForT.aI  Snecification  and  Verification  of  Ada. 

0.3.  Ada>Europe  Formal  Methods  Working  Group 

The  Formal  Methods  Working  Group  of  Ada-Europe  is  preparing  an  Ada  style  guide  for  the  use  of  a 
verifiable  subset  of  Ada  to  be  used  in  the  development  of  programs  intended  to  be  verified.  (It  appears 
that  this  is  the  same  group  that  is  working  on  a  formal  semantics  for  the  language  •  see  Section  12.3.) 


10.  Appendix  C  -  Current  Verification  Systema 

This  appendix  lists  current  efforts  in  verification,  particularly  those  that  are  unrelated  to  the  verification 
of  Ada.  (For  a  list  of  those  efforts  that  are  particularly  related  to  Ada,  see  Appendix  D.)  A  good  starting 
point  for  comparative  evaluati<^  can  be  found  in  [CheheylSl].  Another  evaluation  is  currently  underway 
with  a  report  due  out  this  fall.^  The  current  status  and  point  of  contacts  for  each  of  the  efforts  are  listed 
with  each  effort. 

In  addition,  some  of  the  more  visible  applications  of  each  of  these  systems  are  listed,  with  the  current 
status  and/or  results  of  the  applications.  Points  of  contact  are  also  provided  where  available. 


10.1.  Gypsy  Verification  Environment  (GVE) 

The  following  are  the  first  three  paragraphs  of  "Using  the  Gypsy  Methodology”  [Good84bj.  They 
adequately  describe  the  Gypsy  methodology. 

The  Gypsy  methodology  is  an  integrated  system  at  methods,  languages,  and  tools  for  designing  and  build¬ 
ing  formally  venfied  software  systems.  The  methods  provide  for  the  specification  and  coding  of  systems 
that  can  be  rigorously  verified  by  logical  deduction  to  always  run  according  to  specification.  These 
specification,  programming,  and  verification  methods  dictated  the  design  of  the  program  description 
language  Gypsy.  Gypsy  consists  of  two  intersecting  components;  a  formal  specification  language  and  a 
verifiable,  high  level  programming  language.  These  component  languages  can  be  used  separately  or  collec¬ 
tively.  The  most  important  characteristic  of  Gypsy,  however,  is  that  it  is  fully  verifiable.  The  entire  Gyp¬ 
sy  language  is  designed  so  that  there  exist  rigorous,  deductive  proof  methods  for  proving  the  consistency  of 
specifications  and  programs.  The  methodology  makes  use  of  the  Gypsy  Verifieation  Environment  (GVE)  to 
provide  automated  support.  The  GVE  is  a  large  interactive  system  that  maintains  a  G3rpsy  program 
description  library  and  provides  a  highly  integrated  set  of  tools  for  implementing  the  specification,  program¬ 
ming,  and  verification  methods. 

The  Gypsy  methodology  may  also  be  applied  strictly  to  the  design  phase  of  system  development.  For  ex¬ 
ample  in  certain  applications,  particularly  in  the  security  domain,  it  is  considered  desirable  to  prove  that  a 
system’s  specifications  possess  specific  properties.  In  Gypsy  these  properties  would  typically  be  stated  as 
lemmas  or  as  the  specifications  on  an  abstract  data  type,  and  the  verification  of  the  design  would  consist  of 
demonstratmg  that  the  high  level  specifications  satisfy  these  lemmas  and  type  specifications.  For  more  on 
proving  properties  of  specifications  see  [Good84c|. 

The  effective  range  of  application  of  the  methodology  depends  on  the  applicability  of  Gypsy  to  a  particular 
problem.  Gypsy  Is  suitable  for  a  wide  range  of  general  and  systems  programming  applications.  Gypsy  was 
derived  from  Pascal  and  retains  much  of  the  wide  applicability  of  Pascal.  One  major  exception  is  the  ab¬ 
sence  of  floatmg  point  in  Gypsy.  Gypsy,  however,  does  have  major  facilities  for  exception  handling,  data 
abstraction,  and  concurrency  that  are  not  present  in  Pascal.  During  its  development,  the  methodology  has 
been  used  successively  in  several  substantial  experimental  applications.  These  include  message  switching 
systems,  selected  components  of  an  air  traffic  control  system,  communication  protocols,  security  kernels, 
and  monitoring  of  mter-process  communication. 

For  further  information  on  the  Gypsy  language  and  the  Gypsy  Verification  Environment,  contact: 

Dr.  Donald  Good 

Institute  for  Computing  Science  and  Computer  Applications 

2100  Main 

The  University  of  Texas 

t  The  effort  is  entitled  "Verifleation  Assessment”.  The  point  of  contact  is  Richard  A.  Kemmerer,  Computer  Science  Depart¬ 
ment  University  of  California,  Santa  Barbara,  CA  93108.  (805)-981-<232.  DDN;  dicItOuclaplocus. 


I" 


Austin,  TX  78712 

(512)-471-1901 

goo<i@utcxas>20 

Some  of  the  more  notable  applications  of  Gypsy  and  the  GVE  are  listed  in  the  following  sections.  A 
listing  of  Gypsy  applications  can  be  found  in  [GoodSSj. 


10.1.1.  Encrypted  Packet  Interface 

The  Encrypted  Packet  Interface  (EPI)  [Good82a]  was  the  first  major  trial  application  of  the  GVE.  The 
EPI  is  a  device  that  sits  between  a  host  and  an  IMP  on  the  ARPANET.  Properties  of  proper  encryption 
and  decryption  of  TCP  (4.0)  packets  between  the  two  sides  of  the  EPI  were  specified  and  proved.  The 
code  implemented  interoperated  successfully  across  the  ARPANET  with  a  companion  interface  developed 
and  implemented  independently  in  conventional  assembly  code  at  6BN. 


10.1.2.  Message  Flow  Modulator 
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The  Message  Flow  Modulator  (MFM)  [Good82b]  is  an  LSI-11  based  security  filter  that  monitors  message 
flow  from  the  Ocean  Surveillance  Information  System  (OSIS).  The  MFM  monitors  all  messages  for 
occurrences  of  certain  security  sensitive  phrases.  It  has  been  demonstrated  successfully  in  an  operational 
environment. 


10.1.3.  KAIS  Front  End  Unit 

The  KAIS  (Korean  Air  hitelligence  System)  Front  End  Unit  (h'EU)  is  a  security  filter  that  releases 
messages  segments  from  a  high  security  STREIAMLINER  system  to  a  lower  security  Combat  Support 
System  (CSS).  The  FEU  is  currently  under  development  at  the  University  of  Texas  and  an  attempt  to 
meet  all  relevant  certification  requirements  under  the  AI  criteria  of  the  DoDCSC.  Some  reports  on  the 
KAIS  FEU  include  the  requirements  [Smith84],  design  (security  model  and  top  level  specifications)  [Good 
84a],  and  design  proofs  [Good84e|. 


10.2.  Affirm 

What  follows  is  the  introduction  of  a  brief  paper  put  together  for  the  Verification  Workshop  that  took 
place  in  February.  It  documents  the  current  status  of  the  AFFIRM  system. 

The  affirm  Program  Verification  System  originated  at  the  University  of  Southern  California  Information 
Sciences  Institute  (ISI).  It  is  an  experimental  system  for  the  algebraic  specification  and  venfication  of 
abstract  data  types  and  Pascal-like  programs  usmg  these  types.  AFFIRM-85  is  an  enhanced  version  of  .AF¬ 
FIRM  that  is  being  developed  at  General  Electric  Corporate  Research  and  Development  Center  (GE-CRD) 

This  paper  briefly  describes  two  major  extensions  that  will  be  completed  early  in  1985.  The  pnmary  pur¬ 
pose  of  these  and  several  minor  extensions  is  to  enable  the  use  of  AFFIRM  in  carrying  out  a  larger  part  of 
the  software  development  process  than  previously  has  been  possible. 

The  Hierarchical  Support  mechanism  of  AFFIRM-8S,  has  been  designed  to  support  the  approach  to 
hierarchical  organization  of  abstract  data  types  and  their  implementations,  supplemented  by  a  methoa  of 
connecting  equational  implementations  to  Pascal  procedures  and  functions.  The  Hierarchical  Support 
mechanism,  has  been  implemented. 

The  heart  of  the  AFFIRM  system  is  a  natural  deduction  theorem  prover  for  the  interactive  proof  of  data 
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type  properties  and  verification  conditions.  A  Reusable  Theorems  mechanism  that  allows  the  user  to  keep 
track  of  what  assumptions  a  theorem  depends  on,  even  across  session  boundaries  has  been  designed  and  is 
currently  under  implementation. 

David  R.  Musser 

General  Electric  Research  It  Development  Center 
KW  C285A 
P.O.  Box  8 

Schenectady,  NY  12301 
(518)-387.5964 
DDN;  musser@ge-crd 


10.3.  Hierarchical  Development  Methodology  (HDM) 

HDM,  the  Special  specification  language,  and  the  tools  supporting  the  methodology  and  language  are 
currently  undergoing  enhancements  and  revisions.  From  [Melliar^SmithSS],  goals  of  the  new  system 
include: 

•  Specifications  in  first  order  predicate  calculus  with  second  order  capability 

•  Strong  type  checking  with  overloading 

•  Parameterized  modules  with  semantic  constraints 

•  User  interface  based  on  multi-window  screen  editor  [EMACSj 

c  Theorem  proving  by  reduction  to  propositional  calculus,  with  decision  procedures  for  common  theories 
e  Hoare  sentences  and  code  proof 

•  Multilevel  security  (MLS)  checking  by  information  Sow  analysis 

HDM  and  Special  have  been  used  in  the  development  of  a  number  of  projects,  some  of  which  are  listed 
below.  In  addition,  the  Army  Secure  Operating  System  being  developed  by  TRW  (See  Appendix  A 
Section  8.5)  will  be  using  HDM. 

P.  Michael  Meiliar-Smith 
Computer  Science  Laboratory 
SRI  International 
333  Ravenswood  Ave. 

Menlo  Park,  CA  94025 
melliar-smith<9sri-c3l 


10.3.1.  System  Implemented  for  Fault  Tolerance  (SIFT) 

Although  a  significant  amount  of  work  was  completed  under  the  auspices  of  this  effort  [LevittSSbl,  it  is 
not  clear  that  the  effort  indeed  provided  the  sorts  of  results  that  were  being  sought  or  in  the  particul9r 
areas  being  investigated.  In  a  peer  review  of  the  results  obtained  in  the  effort  [SIFT),  a  significant  amount 
of  disagreement  over  the  claimed  results  surfaced. 
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10^^.  Kernelixed  Secure  Operating  System  (KSOS) 

KSOS  was  begun  with  the  goal  of  designing,  implementing,  and  proving  a  secure  operating  system. 
[Benonj.  Some  twenty  levels  of  abstraction  were  written  in  Special  describing  the  design  of  the  system. 
An  implementation  was  then  developed  that  runs  insufficiently  fast  to  be  of  any  use  for  development  of 
significant  applications. 


10.3.3.  Probably  Secure  Operating  System  (PSOS) 

PSOS  was  designed  using  HDM  by  organising  a  collection  of  approximately  20  hierarchically  related 
modules  [Feiertag].  The  baaing  mechanism  underlying  the  PSOS  was  that  of  a  capability  machine.  No 
implementation  has  been  constructed. 
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10.3.4.  Honeywell  Secure  Communicadons  Processor  (SCOMP) 

Honeywell,  in  concert  with  the  DoDCSC,  developed  the  SCOMP,  a  communications  processor  derived 
from  the  Honeywell  Level  8  computer,  with  additional  hardware  for  memory  management  and  protection. 
The  SCOMP  was  specified  in  Special  (with  trusted  processes  in  Gypsy),  verified,  then  implemented  in  C 
Pascal.  It  has  received  an  A1  rating  from  DoDCSC. 


10.4.  Formal  Development  Methodology  (FDM) 
No  information  has  been  received  on  FDM. 


CooperQMIT'Muitics 


10.5.  Module  Verification  System 

The  Modula  Verification  System  (MVS)  is  an  attempt  to  apply  verification  techniques  and  principles  to 
Module.  In  this  application,  there  has  been  no  serious  attempt  to  keep  to  the  de^ition  of  the  Modula 
language,  and  as  a  result,  programs  written  in  “verifiable  Modula”  are  not  processible  by  Modula 
compilers.  One  major  feature  of  Modula  that  was  omitted  was  that  of  concurrency.  In  addition  to  the 
parser  a  verification  condition  generator  and  theorem  prover  have  been  implemented. 

(The  efibrt  in  the  MVS  has  also  resulted  in  an  attempt  to  convert  the  MVS  into  an  Ada  verification 
system.  This  latter  effort  is  documented  in  Appendix  D,  Section  11.5.) 

Professor  Ray  Hookway 

Department  of  Computer  Engineering  and  Science 
Case  Western  Reserve  University 
Cleveland,  OH  44106 
(216)-368-2800 

DDN:  hookway%caseQcsnet>relay 


10.6.  Verus  Verification  System 

The  VERUS  Verification  System,  developed  at  Compion  (formerly  DTI)  is  now  undergoing  product  review 


-  U 


by  Gould  in  preparation  for  marketing.  It  had  been  used  at  Compion  for  several  internal  developments. 

Liza  Nowell 
Product  Planning 
Gould  Computer  Systems 
6901  W.  Sunrise  Blvd. 

Fort  Lauderdale,  FL  33313 
(305)-797-5733 
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11.  Appendix  D  •  Current  Adn  Veriflention  Efforts 

This  appendix  lists  the  current  known  efforts  in  verification  that  are  particularly  aimed  toward  the  Ada 
programming  language  and  toward  developing  systems  for  automated  support  of  verification.  It  also 
includes  those  efforts  that  are  more  directed  toward  the  language  itself,  but  looking  at  verification  issues 
as  well.  Status  of  the  various  efforts,  as  well  as  points  of  contact  are  provided. 

11.1.  Anna  Specification  Language 

From  the  Preface  to  the  Preliminary  Reference  Manual  for  Anna  [Luckham84j ; 

Anna  is  a  language  extension  of  Ada  to  include  (au:ilities  for  formally  specifying  the  intended  behavior  of 
Ada  programs.  It  is  designed  to  meet  a  perceived  need  to  augment  Ada  with  precise  machine-processable 
annotations  so  that  well  established  formal  methods  of  specification  and  documentation  can  be  applied  to 
Ada  programs. 

A  number  of  documents  in  addition  to  the  reference  manual  are  in  process,  including;  (1)  an  introduction 
to  the  use  of  Aima;  (2)  transformations  from  annotations  to  Ada  runtime  checks;  and  (3)  an  axiomatic 
semantics  of  Anna. 

Current  (and  planned)  tools  include:  (1)  syntax  analyzers,  structured  editors,  tools  for  detecting  simple 
kinds  of  errors;  (2)  a  runtime  checking  system  that  will  translate  most  annotations  into  Ada  runtime 
cheeks.  A  formal  verification  system  is  regarded  as  a  longer-term  undertaking. 

Professor  David  Luckham 
Stanford  University 
ERL  428  CSL 
Stanford,  CA  94305*2192 
(4i5)-497.1242 
DDN:  luckham<3su-ai 


11.2.  Asphodel  Specification  and  Design  Language 

An  effort  in  Europe  has  lead  to  the  development  of  a  specification  language.  Asphodel  [Hilll,  similar  in 
style  to  Anna  for  the  use  of  design  and  specification  of  Ada  programs.  The  langtiage  is  designed  to  be 
more  in  the  style  of  the  Vienna  Development  Method  [Bjomer]  rather  than  that  of  the  algebraic  style 
[Guttag]. 

Alec  Hill 

Central  Electric  Generating  Board 

Computing  and  Information  Systems  Department,  Laud  House, 

20  Newgate  Street,  London  EClA  TAX,  UJC. 

11.3.  Cornell  Attribute  Grammar  Tools 

The  Cornell  Attribute  grammar  tools  have  been  considered  for  use  in  the  development  of  an  Ada 
verification  system.  This  development  could  occur  by  generating  a  formal  description  of  Ada  annotated 
with  attributes,  and  run  through  the  various  tools.  This  idea  was  first  suggested  in  [Reps84],  and  is 
currently  under  investigation. 


Ryan  Stansifer 
Cornell  University 
Ithaca,  NY  141850 


11.4.  Prototype  Ada  Verification  System 

Verdix  Corporation  is  currently  investigating  the  development  of  a  prototype  Ada  verification  system 
based  upon  the  modification  of  its  own  validated  Verdix  Ada  Development  System  (VADS)'^™  and  the 
Gypsy  Verification  Environment  developed  at  The  University  of  Texas.  The  front  end  of  the  VADS  is 
being  modified  to  accept  not  only  Ada,  but  Annsplilce  annotations  as  well.  Once  the  syntactic  and 
semantic  parsing  have  been  completed,  the  resulting  Diana  structures  will  be  passed  through  a 
“verification  filter”  to  check  that  an  acceptable  “verifiable  subset”  of  the  Ada  language  is  being  used. 
This  will  then  result  in  a  database  of  structures  suitable  for  reading  into  the  GVE  for  verification 
condition  generation  and  theorem  proving.  This  effort  is  expained  in  greater  detail  in  [McHughSS]. 

Karl  Nyberg 
Verdix  Corporation 
7855  Old  Springhouse  Rd. 

McLean,  VA  22102 
(703)-448-1980 
DDN:  nyberg<9eclb 
UUCP:  vrdxhqikarl 


11.5.  Modula  Verification  System  Conversion 

The  Modula  Verification  System  developed  at  Case  Western  is  currently  undergoing  modification  to 
attempt  to  turn  it  into  an  Ada  verification  system.  The  basic  premise  is  that  a  lot  of  verifiable  Modula 
will  be  similar  to  verifiable  .4da.  A  particular  example  cited  is  that  of  the  similarity  private  types  m  .-Kda 
and  exported  types  in  Modula.  The  programs  accepted  by  the  verification  system  are  in  a  modified  .\da 
syntax  to  include  pre-  and  post-conditions  and  other  constructs  necessary  for  verification,  and  the  system 
will  output  a  version  of  the  programs  acceptable  as  input  to  an  Ada  compiler.  No  semantic  checking  of 
types,  overloading,  or  any  other  constructs  that  a  validated  compiler  is  expected  to  catch  are  made. 

The  CTirrent  system  consists  of  a  parser  (based  upon  Herm  Fischer’s  grammar),  the  front  end  of  a 
verification  condition  generator,  and  supports  library  constructs.  The  semantic  pans  of  the  verification 
condition  generator  are  currently  under  design  and  development. 

Professor  Ray  Hookway 

Department  of  Computer  Engineering  and  Science 
Case  Western  Reserve  University 
Cleveland,  OH  44106 
(2ia)-368-2800 

DDN:  hookway %case<9csnet-relay 


11.6.  NSA  Internal  Efforts 

A  number  of  efforts  are  gomg  on  within  the  Department  of  Defense  Computer  Security  Center  Those 
that  are  listed  here  deal  only  with  the  particulars  of  the  development  of  verification  technology  for  Ada. 


Vtrdix.  VaDS  »rt  trmdtmarki  of  Vtrdix  Corporuion 


(Other  NSA  efforts  are  listed  in  Appendix  A,  Section  8.7.)  The  two  particular  areas  in  Ada  verification 
that  are  being  pursued  are  the  investigation  of  the  verifiability  of  Ada  —  how  restricted  would  a  verifiable 
subset  have  to  be,  and  the  development  of  tools  for  performing  the  automated  verification  of  Ada.  Efforts 
underway  in  the  second  area  include  both  inhouse  and  pending  proposed  efforts. 

Brian  Holland 

DoD  Computer  Security  Center,  C3 
9800  Savage  Road 

Ft.  George  G.  Meade,  MD  20755-6000 

(301)859-6968 

DON:  brian<9tycho 


12.  Appendix  E  •  Working  Groups 


This  appendix  lists  current  known  efforts  aimed  at  investigating  the  development,  deployment  and  usage 
verification  techniques  in  the  development  of  systems  using  Ada. 


12.1.  IDA  Workshops  on  Formxl  Specification  and  Verification  of  Ada 

The  Institute  for  Defense  Analysis  (IDA)  is  conducting  workshops  on  formal  specification  and  verification 
of  Ada.  The  first  workshop  was  held  in  March  1985,  and  the  second  is  planned  for  mid  to  late  summer 
1985.  The  first  Workshop  on  Formal  Specification  and  Verification  of  Ada  resulted  in  a  set  of  proceedings 
(currently  in  draft  form)  and  the  establishment  of  several  working  subgroups.  These  subgroups,  and  the 
status  of  their  efforts  are  presented  in  the  following  sections.  Although  some  of  the  subgroups  might  be 
more  appropriately  listed  in  other  Appendices,  they  are  included  here  for  consistency,  and  cross  referenced 
where  appropriate. 

Dr.  Jack  Kramer 

Institute  for  Defense  Analyses 

1801  N.  Beauregard  St. 

Alexandria,  VA  22311 
(703)  845-2263 

DDN ;  kramer@eclb 


12.1.1.  Scctirs  Systama 

The  goal  of  this  working  subgroup  is  to  attempt  to  determine  the  suitability  of  Ada  for  use  in  the 
development  of  secure  systems,  particularly  those  intended  to  I  *  ..ubmitted  to  the  DoDCSC  for  ratings  at 
or  above  the  B2  level.  The  chair  of  this  subgroup  is  attempting  to  coordinate  efforts  with  the  Ada  Task 
Force  (see  Appendix  A,  Section  8.7.1)  which  has  a  similar  charter. 

Margie  Zuk 
MITRE  Corporation 
Burlington  Road 
Bedford,  MA  01730 
(817>.271.7590 

DDN:  security !mmz<9mitre-bedford 


12.1.2.  Near  Term  Verification 

The  goal  of  this  working  group  is  to  investigate  the  near  term  needs  and  solutions  for  dealing  with  Ada 
verification.  In  particular,  automated  tools  for  the  support  of  verification  in  the  near  term  are  being 
investigated.  Participation  in  the  group  through  dissemination  of  network  mail  has  begun. 

In  addition  to  the  efforts  uncovered  during  the  IDA  workshop,  several  verification  and  Ada  related 
projects  are  being  investigated.  Ther't  include; 

•  Ada  based  fault-tree  analysis  being  done  by  Nancy  Leveson  at  UCI. 

•  An  Ada  to  Special  Sow  tool  being  developed  by  Compusec. 

•  Application  of  IBM’s  venfication  methodologies  known  as  the  "Clean  Room  ”  approach  to  Ada 


It  is  hoped  that  the  working  group  will  meet  prior  to  the  next  IDA  meeting,  possibly  in  early  July  at  RTI. 

John  McHugh 
Research  Triangle  Institute 
Box  12194 

Research  Triangle  Park,  NC  27709 

(919)-541-7327 

DDN:  mchugh®utexas>20 


12.1^.  Formal  Somantica 

This  subgroup  is  involved  in  Investigating  the  areas  of  a  formal  semantics  for  the  language,  both 
sequential  and  concurrent.  Contacts  with  other  organizations,  particularly  in  Europe,  who  have  similar 
interests  have  been  made,  and  plana  are  to  convene  a  one-day  meeting  this  summer,  hopefully  just  before 
the  second  IDA  workshop. 

Norm  Cohen 
SofTech,  Inc. 

705  Masons  Mill  Business  Park 
1800  Byberry  Road 
Huntingdon  Valley,  PA  19006 
(215)-947*8880 
DDN:  ncohenQeclb 


12.1.4.  Speeifieatioa  Languages 

No  response  has  been  received  from  this  chair. 

Friedrich  von  Henke 
SRI  International 
333  Ravenswood  Avenue 
Menlo  Park,  CA  94025 
(415)-859-2560 
DDN:  vonhenke^sh-csl 


12.1Ji.  Verification  in  Life  Cycles 

This  subgroup  is  looking  into  how  to  integrate  formal  verification  techniques  with  other  software 
development  practices  in  the  software  life  cycle.  Coordination  with  other  groups  pursuing  similar 
interests  (such  as  the  ACM  group  mentioned  in  Appendix  B,  Section  8.1)  is  intended.  An  interim  meeting 
is  planned  before  the  next  IDA  workshop. 

Ann  Marmor-Squires 
TRW,  Defense  Systems  Group 
2751  Prosperity  Avenue 
Fairfax,  VA  22031 
(703)  876-8170 
DDN:  marmor<3isi 


12.1.6.  Clusters 


This  working  group  is  investigating  an  Odyssey-specific  approach  to  the  development  of  multiple,  possibly 
overlapping  subsets  of  Ada  for  use  in  various  software  developments.  From  discussions  with  the 
chairman,  it  appears  that  there  is  little  involvement  from  others  outside  of  the  company. 

Ryan  Stansifer 

Odyssey  Research  Associates,  Inc. 

408  E.  State  Street 
Ithaca,  NY  14850 
(607)  277-2020 
DDN:  rplatek<3eclb 


12.2.  Ada  Task  Force 

The  DoDCSC  has  convened  an  Ada  Task  Force  to  investigate  the  suitability  of  Ada  in  the  development  of 
secure  computing  systems.  Little  is  known  about  the  efforts  of  this  group,  as  the  head  of  the  task  force 
(listed  below)  has  denied  access  to  any  minutes  or  proceedings  of  the  groups  only  meeting  to  date. 

Marv  Schaefer 
DoDCSC,  C3 
9800  Savage  Road 

Ft.  George  G.  Meade,  MD  20755-6000 

(301)-859-6380 

DDN:  schaefer^isi 


12.3.  European  Efforts  on  Formal  Senumtiea 

An  effort  is  underway  in  Europe  for  the  development  of  a  draft  Ada  language  formal  definition  (Ada  FD). 
This  effort  is  supported  by  the  EIEC,  and  is  being  performed  at  Dansk  Datamatik  Center.  The  major 
goals  of  the  project  are  [EEC]: 

To  obtain  as  concise  a  definition  of  the  full  ANSI  Ada  language  as  is  today  feasible,  in  a  form  which 
(0)  May  serve  as  a  reference  for  questions  on  Ada, 
and  is  suitable  for  further  research  on  the  following  topics: 

(1)  formal  work  in  the  areas  of  proof  systems  for  Ada  programs, 

(2)  correct  development  of  correct  Ada  interpreters  and  compilers, 

(3)  the  meaningful  generantion  and  verification  of  Ada  test  programs,  including  validation  of  the  ACVC 
test  suite,  and 

(4)  the  denvation  of  informal,  but  precise,  unambiguous  Ada  reference  manuals  for  various  user  groups, 
in  order  to  help  provide; 


•  input  to  the  ongoing  standardization  work  on  Ada.  in  particular  to  support  the  ISO  rfuture  review  of  the 


Ada  standard,  and 


•  a  worthy,  broad,  and  commoniy  accepted  candidate  for  the  formal  component  of  a  future  Ada  ISO  Stan¬ 
dard. 

Some  subsidiary  objectives  include: 

•  To  help  unite  various  approaches  to  the  informal,  and  semi-formal  descriptions  of  Ada  (by  studying  bow 
to  relate  the  proposed  Ada  FD  to  e.g.  the  bfYU  SETL  interpreter  for  Ada). 

•  To  further  develop  and  research  engineering  methods  suitable  for  the  precise  definition  of  large,  complex 
software  systems  (by  calling  on  a  wide  community  of  computer  scientists  to  take  part  both  in  the  actual 
Ada  FD  development,  and  its  review),  and  thereby 

•  to  further  propagate  the  use  of  formal  methods  in  software  engineering. 

Contracting  Agency; 

Rudolf  W.  Meijer 

Commission  of  the  European  Communities 

Information  Technology  and  Telecommunications  Task  Force 

A25  9/6A 

Rue  de  la  Loi  200 

B-1049  Brussels,  Belgium 

tel:  +  32  2  235  7789 

telex:  21877  comeu  b 

telecopier  +32  2  235  0655 

DDN:  rmeijer<9eclb 

UUCP:  ...!decvax!mcvax!hrc63!rmeijer 


Contractor: 


Kurt  W.  Hansen 
Dansk  Datamatik  Center 
Lundtoftevej  1C 
DK-2800  Lyngby,  Denmark 
tel  +45  2  872622 
telex  37704  ddc  dk 
telecopier  +45  2  872217 
DDN:  khanaen<Qeclb 
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